A brief historical rundown on COM?s glorious past
COM began as Object Linking and Embedding, which we all know as OLE. Basically, OLE allows a client application to store data from a server. It also contains information on how to get that server kick started whenever the server is needed. OLE has theoretically been discontinued by you-know-who and the term COM should be used instead. These days, OLE is used to refer to the higher level features that are constructed on top of COM technology.
COM stands for Component Object Model. It allows you to create COM objects that are not specific to any language, and in some cases, even platforms. For instance, COM objects can be ported to a Unix system. COM also allows you to create COM Objects that will be instantiated on a different machine across the world if you so desired. COM programming brings programmers the following benefits:
* Create objects that can be used by multiple programming languages
* Create ActiveX controls
* Control other programs via OLE automation (like MSWord, Excel, I.E)
* Work with objects or programs on other machines (DCOM)
Abstract methods vs. Interfaces
Before we learn how to use Interfaces, we are going to need to understand whence the theory originates. Thus, we will discuss Abstract methods. Let us examine the following chunk of code. Pay special attention to the way virtual, abstract, and override are used.
type
TSomeNumber = class
public
function SomeString: string; virtual; abstract;
end;
TSomeInteger = class(TSomeNumber)
private
FValue : Integer;
public
function SomeString: string; override;
end;
TSomeDouble = class(TSomeNumber)
private
FValue : Double;
public
function SomeString: string; override;
end;
After your classes are defined, you can create a procedure called ShowSomeNumber as shown below.
procedure ShowSomeNumber(F : TSomeNumber);
begin
ShowMessage(F.SomeString);
end;
Below is an example of how you can create two different classes, but pass either of them into ShowSomeNumber. ShowSomeNumber will then call the appropriate method for the class that was passed in.
var
MyDouble : TSomeDouble;
MyInteger : TSomeInteger;
begin
MyDouble := TSomeDouble.Create;
MyInteger := TSomeInteger.Create;
try
ShowSomeNumber(MyDouble);
ShowSomeNumber(MyInteger);
finally
MyDouble.Free;
MyInteger.Free;
end;
end;
As we can see, ShowSomeNumber does not care if you pass in a TSomeDouble or a TSomeInteger. Since both of those classes were derived from the class TSomeNumber that contains the abstract method SomeString, you can call the sub-classes implementation of SomeString by calling F. SomeString. It is also important to note that you should not create an instance of TSomeNumber class. If you try to compile code in which you create a direct instance of this class, you will receive the following warning from Delphi:
"[Warning] COMCodeExample1_Unit.pas(126): Constructing instance of 'TSomeNumber' containing abstract methods"
Obviously, Delphi is concerned that you are creating a class that implements nothing. Let us see what happens if you decide to create an instance of this class and then try to call SomeString.
var
F : TSomeNumber;
S : string;
begin
F := TSomeNumber.Create;
S := F. SomeString;
F.Free;
end;
If you executed this program, you would receive the abstract warning from Delphi and then you would receive the following exception from the OS for obvious reasons: "Abstract error!".
You cannot access a method that has no implementation. There is nothing to access! It is also interesting to note that Delphi will not you to do CTRL-SHIFT-C for code completion in the class that contains the abstract method. It knows that if it is declared as abstract that it cannot implement it! Clever clever?.
These concepts may seem difficult to grasp, but it must be understood in order to understand how COM technology operates. Refer to COMCodeExample1 to see an actual program that incorporates this concept.
Classes and Interfaces: An interesting paradox
The way in which an Interface functions is really no different than a class that only contains abstract methods. The functionality is the same, however, the way you create an interface and use them is different than that of a class. So, let us establish a rule. Interfaces are not classes. They are an independent construct that has it?s own set of rules just like classes do. They have some similarities, but it is easier to think of them as entirely different branch of the language.